Floppyshop 2/Floppyshop - 2.zip/Floppyshop - 2.iso/diskmags/0022-3.564/dmg-0089/506.txt

Text File | 1997-04-16 | 16KB | 324 lines

INFO-ATARI16 Digest         Wed,  2 May 90       Volume 90 : Issue  506

Today's Topics:
                              DCDESKTOP
                      Fading SM124 inverse video
             STE investigation/ docs discussion [large!]
                        Supercharger problems
----------------------------------------------------------------------

Date: 2 May 90 19:34:38 GMT
From: isc-br!techpub3![e-mail]  (Lawrence Kelley)
Subject: DCDESKTOP
Message-ID: <[e-mail]>

I ran the DCdesktop demo last night.  I didn't have time to give it a
complete workout.  However, I noticed that TurboST clobbers it when it
attempts to load.  Maybe I have an old version.

Anybody know if it Will run okay with the latest version?

Shalom, lawrence

------------------------------

Date: Wed, 2 May 90 19:29:20 BST
From: Ian D Hawkins
 <[e-mail]>
Subject: Fading SM124 inverse video
Message-ID: <[e-mail]>

My thanks to those who replied to my posting on the subject of dimming
SM124 white characters on black background;  It appears lots of people
have had this problem but no one knows the solution.  Suprisingly,  Atari
UK claim to know nothing of this 'feature' of their monitor.  The
phenomenon seems limited to 'heavy' SM124 models that use a large mains
transformer,  later versions using a light switched mode PSU are not
affected,  neither are SM125 monitors.  A service man (Charles)
fom Silica shop seemed more helpful,  and said he would investigate the
problem if he could reproduce it on his SM124.  Since the Germans seem
to be the best ST hardware hackers around perhaps a German reader of
this BBS may have read of this and be able to shed light on the topic.




------------------------------

Date: 2 May 90 11:34:00 GMT
From: mcsun!ukc!newcastle.ac.uk!turing![e-mail]  (J. Derrick)
Subject: STE investigation/ docs discussion [large!]
Message-ID: <[e-mail]>

[this message is a bit big- contains some discussion then my STE hardware
findings]

Whew! I've been away from the net for a bit due to work and machine problems,
so I've only just caught up with the discussion about the STE and documentation
for its new features. Here's my opinions:

- I agree totally with Allan Pratt that blindly dissasembling the ROMS and
  using what you find blatently will result in hack code that is very likely
  to be incompatible with anything apart from the machine it came from
  [remember all the 1.09 stuff]. I therefore never intend to pass on shaky
  information such as ROM vectors [very likely to change], and TOS specifics
  [where I just don't know enough to comment]. I also don't want to wander into
  a copyright minefield.

- I also agree totally that what is needed is *official data*. I would dearly
  love to become a developer and burn my copy of INTERNALS. Unfortunately I
  can't. [note I'm under Atari UK, not America]. To give credit where its due,
  over there Atari appears to be improving its support to earn its cash more.
  However, in the UK it costs 300 pounds [$500] to become a developer. I'm a
  student- that represents my grant for a whole term! It would take Devpac 2 and
  Lattice C v5 to be bundled before I could even begin to justify that sort of
  cost for support- all I really need is docs, I'm not a company!

- I received 6 A4 sheets extra manual with my STE. I think that is unreasonable
  considering the changes from the ST. Okay, I got it for a bargain 260 pounds
  pre-release [$400]- I don't know the current situation, but there are _NO_
  other docs avaliable. No Atari stuff, no third party stuff yet. I have been
  forced to hack. I am a software engineering student- I hate hacking; I want
  accurate docs, not hearsay. My thanks go to Mathew Lodge who has done a
  great deal to spread 'good', 'accurate' information. My pleas go to Atari for
  docs only, say <100 pounds [$160]- I can afford that, and still should be
  profitable for you.

- Thanks are due to Allan Pratt for keeping up with these discssions and
  replying from an 'insiders' viewpoint [I hope that says what I mean]. Due to
  differing intrests your messages are some of the most debated, but I hope
  this is taken as a complement. Your time and opinions are definately valued
  here.

With these topics firmly in mind, and armed with Mathew Lodge's posting I've
updated my findings, and include them here. Thanks to all who wrote and
expressed an intrest- sorry for the delay- troff'ing a thesis/exams and system
problems are keeping me busy!

I also have a _very_ simple test prog which displays the port values, which if
I can work out how/get time may get posted to binaries.

--------------------------------axe murder here--------------------------------

STE Joysticks/ROM
-----------------
Please note this information is largely derived from my own findings, and is
not backed up with hard Atari fact. I accept no responsibility for errors or
omissions, and give the warning that serious damage could result from
experimentation. Please don't blame me if your STE shorts out and expires! All
details could be fatally flawed and subject to change in the future causing
compatibility problems- please use only for personal experimentation and not
full program devlopment. I include specifics for general information only. My
opinions of disclaimers are my own.

The only data Atari gives for the new connectors is the plug signals contained
in the single sheet STE addendum, thus my only way forward was to look in the
ROM.

Looking at the system variable _sysbase [$4F2.L], the STE rom appears to have
moved down to $E00000, which is bourne out by the exception vectors. My
dissasembler would not look at this area, so I wrote a 68K routine to go into
supervisor mode and dump the memory to disk. This uses GEMDOS Fwrite to save
the rom a long word at a time. This is very inefficient, but it didn't like
saving large chunks [I'm new to 68K on the STE, so there's doubtlessly a better
way].

From this, the rom data lies in the range $E00000-$E31B48. My UK TOS 1.6 is on
2 EPROMS, both apparently 27C010-250, with the upper space empty. Looking
through the code, it resembles the dissasembly in ST Internals, but with many
improvements and additions for the new hardware.

The BIOS and XBIOS trap handlers appear much the same as before, but there seems
to be an extra XBIOS call $40. This seems to look at $FF8A00, and check for a
bus error. Its purpose is unknown.

Going through the initialsation stuff, the code is also mostly as before.
Memory clearence is now faster, with a few extra writes in the loop. To support
the new hardware, code has been added, notably around $E002C4. The DMA sound is
initialised [$FF8900] and the tone control acessed via the microwire bus
[$FF8922,4]. There seem to be a number of new system variables, for instanve
look at $980 onwards. These locations come complete with text names: _VDO,
_MCH, SND, _SWI. _SND is set up according to $FF9200, which after a bit of
experimentation turned out to be the new joystick ports. Again this is for
information only- their pupose is unknown.

Inside the STE, the joystick ports are 3 74LS244 octal buffers, 1 74LS373 octal
latch, and 2 NE556 dual timers. From the addendum, the ports give 4 switched
sticks and 2 analog proportional sticks, or 4 paddles. I can't wait for the
flight simulators complete with a proper yoke, although things like temperature
measurement should be posible [watch this space!].

The timers form a simple ADC, wired as a monostable and connected to the new
GLUE chip [? this is a bit uncertain without data]. They seem to be a voltage
to frequency converter. I traced this much:

            |--------|       |--------|       | |
    +5V-----|   1M   |---*---|  470R  |---*---| |-----------0V
            |--------|   |   |--------|   |   | | 680pF
                         |                |
 To input via a choke----|             ---*---
                                       |     |
                                 DISCHARGE THRESHOLD
                              556 wired as a monostable

By varying the input, the duration of the timers pulse can be altered. If this
was measured by a counter after a RESET or TRIGGER, the position of the stick
could be determined. From Matthew Lodge's data they end up as a byte value in
the following locations:

      Paddle 0X  $FF9211    [all byte values]
      Paddle 0Y  $FF9213
      Paddle 1X  $FF9215
      Paddle 1Y  $FF9217

After some experimentation, their detail is still sketchy. They float
unconnected at around $80 [half range?] suggesting 0-255. Using a 100k pot
connected to +5 and 0V varying the input voltage, strange results are
obtained. From 5V to about 3.5V the value rises from around $05-$40. Below this
the ports are not updated and contain garbage. Around this point the pot DC
voltage mysteriously goes low- try a scope to see the 555 oscillations?

By using current drive instead of voltage [connect a pot between +5V and the
input] more meaningful results are gained. With a 100K pot the value varied in
a log manner $05-$15. With the right value pot this may be the correct
usage. Anyone have paddles for a CBM64 or 8bit Atari to look back and check?

The digital standard stick inputs are a little simpler. Four sets of FIRE, UP,
DOWN, LEFT, RIGHT give 20 lines. These are arranged as 12 inputs and 8
bidirectional lines. Matthew Lodge suggests all lines are bidirectional, but
this may be misleading- the chips suggest 24 inputs and 8 outputs, which fits
with what I have found. This arrangement allows far more than just a simple
switched joystick to be connected- 6 inputs, 4 outputs and 2 analogue lines per
connector.

A quick note on the plug: the STE uses a special D connector, with 15 lines
encased in a standard 9-way sized shell. These are fairly new, but a few firms
list them [check stocks though- try Electrovalue [phone], part no.
DP15HD, or Verospeed (UK firms)]. You want a 15 way high-density male D-plug
and a standard 9-way hood [optional cover]. Unfortunately the case design means
that the side lugs need to be hacksawed off to fit- solder the sawed plug
housing together, and glue/file the hood to shape [try it- you'll understand!].

Solid core wire will fit the holes for experimentation, but use thin stuff to
avoid damaging the sockets. This method is also prone to shorts and errors!

The ports appear to be arranged as follows:

$FF9201 [READ]      $FF9202 [READ]      $FF9203 [R/W]
--------------      --------------      -------------
 B0 - FIRE 0          B0 - RT 2          B0 - RT 0
 B1 - FIRE 2          B1 - LT 2          B1 - LT 0
 B1 - FIRE 1          B2 - DN 2          B2 - DN 0
 B3 - FIRE 3          B3 - UP 2          B3 - UP 0
 B4 -   ?             B4 - RT 3          B4 - RT 1
 B5 -   ?             B5 - LT 3          B5 - LT 1
 B6 -   ?             B6 - DN 3          B6 - DN 1
 B7 -   ?             B7 - UP 3          B7 - UP 1

$FF9203 can be read as the other ports, but if it is written to, the '373 latch
kicks in to action, and those 8 connections become outputs. If a read is
subsequently performed, the lines become inputs again, although it may take 2
tries to get valid data from the port [the first reads the output states, then
switches them to inputs for the next attempt].

I have not tried fitting a light pen/gun, but the input seems to be FIRE0. A
logic pulser applied here alters the position registers at $FF9220 and $F9222.
I've used a photodiode and amp or a sweet spot device [all in one] for other
machines [BBC micro & CBM64] so this may be the correct method. Dig up those
old video game light guns! [Make certain you know what you are doing though-
they will require hardware mods!]

If you take the STE apart, be wary of the SIMMS- mine died with vertical lines
on the screen due to a bank of RAM loosening after flexing the board. A bit of
gentle pressure on all the socketed compolents fixed things, with an almighty
sigh of relief! This also caused a problem when upgrading to 1M. Cut thin
pieces of cardboard to fit in the keyboard side of the SIMM holders to gently
push them forward and prevent wobbles [any one remember the ZX81 (TIMEX 1000)!]
Also REMEMBER TO TAKE STATIC PRECAUTIONS. If you don't know what/why don't do
it!

On the whole the STE seems very well designed, and a definate credit to ATARI.
I like the hardware [the colours and the new ports are well designed], and the
new TOS seems to have a few extras in addition to the obvious [I love the left
mouse button for scrolling up text]. What a pity the documentation isn't out
yet.

Yes, I know my STE is pre-relese [260, proposed relese price 399], but I'm
dying for some data, and just can't afford 300 pounds to become a developer.
Are there any _good_ books out there? [what are the Compute series like?] I'd
kill for a circuit diagram! Mathew Lodge has done a great job publishing what
he can, dispelling a few rumours, and helping STE programmers be more accurate.

Share and Enjoy,

James Derrick.

[e-mail]
[Bugged .sig follows!]
| James Derrick                                                              |
| Pt III Microelectronics & Software Engineering            'Don't Panic:    |
| University Of Newcastle Upon Tyne                          Computers can   |
|                                                            smell panic!'   |

------------------------------

Date: 2 May 90 20:28:04 GMT
From: clyde.concordia.ca!mcgill-vision!quiche!calvin![e-mail]  (Sam
 Alan EZUST)
Subject: Supercharger problems
Message-ID: <[e-mail]>

Here is a sequel to my original article, now that I have a bit more
information. It is basically a point-by-point breakdown of my
impressions on the package.

Problems:

1] Hercules graphics mode is a little screwy.
  I try it on my mono monitor and about one  inch of the screen's image
  is cut off at the right of the screen. If anyone else experiences
  this, send me mail. I am really concerned about this bug.

  CGA works fine, so I can still do graphics on most programs,
   such as WP with its equation editor.

2] The built-in font is not very pretty. They should've just used the
   system font.

3] The power cord which plugs into the joystick is a stupid idea. I bought
   a transformer. Which is required for STs with more than 1 mb of memory
   (and since I have one, I had no choice).

4] The Supra Clock reader program (and others, so I am told) will bomb
  while running unless the reset button on the Supercharger is held down.
  This means that supra users can't re-enter into IBM mode unless
  they disable the clock., because the hotkey which exits
  out of ms-dos mode reboots the ST.
  This also means that the reset key must be held
  down every time you boot up the ST (if you want the clock) which
  is also a pain.

5] Print spoolers interfere with the MS-Dos printing, so these must
   be disabled before running supercharger.

good points :

1] Factory setup of software and hardware automatically scans for all
  physical and logical drives, and installs them for you, and the
  ibm's clock is set to the same time as the ST's clock.

2] ST disks can be read without any problems. The ST's mouse can emulate
   an MS - Mouse.


--
|S. Alan Ezust                                |  [e-mail]|
|McGill University School of Computer Science |  Montreal, Quebec, Canada   |
|---------------------------------------------------------------------------|
|                     "The mind is a terrible thing...."                    |

------------------------------

End of INFO-ATARI16 Digest V90 Issue #506
*****************************************